home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 850 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.6 KB
  1. Path: news.bridge.net!news
  2. From: David Byrden <100101.2547@compuserve.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Volatile-Correct; a useful concept?
  5. Date: 7 Jan 1996 22:19:27 GMT
  6. Organization: self-employed
  7. Message-ID: <4cpgtf$hlc@news.bridge.net>
  8. NNTP-Posting-Host: ppp-mia1-39.bridge.net
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset=us-ascii
  11. Content-Transfer-Encoding: 7bit
  12. X-Mailer: Mozilla 1.1N (Windows; I; 16bit)
  13.  
  14.  
  15. A thought for multithreaded & system programmers;
  16.  
  17.  
  18. With the mainstream of programmers moving to multithreaded
  19. code on Win32, the 'volatile' qualifier is no longer something
  20. that only the writers of device drivers need use.
  21.  
  22. (For those who don't recall, 'volatile' on a variable means 
  23. that it may change due to outside forces, i.e. it is not a 
  24. passive piece of RAM. The compiler will therefore read its
  25. value each time you use it in your code, not making
  26. optimisations.)
  27.  
  28. A plain variable shared between two threads may need the 
  29. volatile qualifier, depending on how it is used. 
  30.  
  31. However, I have seen no consensus of opinion on what 'volatile'
  32. means with respect to class objects.  Only 'volatile' member 
  33. functions may be called on an object declared 'volatile'. 
  34. But what are we to DO with this fact? Class objects having more 
  35. than one data member of a built-in type, are not safe to share
  36. between threads just because you declare them 'volatile'.
  37.  
  38. I propose the concept of a class being "volatile-correct" in a
  39. mannar analogous to the concept of "const-correctness". A
  40. class object declared 'volatile' could be SAFELY USED BY
  41. MULTIPLE THREADS. Its volatile member functions would
  42. internally protect its data by mutexes.
  43.  
  44. The class could have non-volatile member functions which could 
  45. be used on object NOT declared volatile; thus, a volatile reference
  46. to an ordinary object oculd be passed to two threads so they 
  47. could share it safely, but its creator would have more efficient 
  48. access to it, without mutexes being involved.
  49.  
  50. The drawback of this scheme is that a 'volatile' member function 
  51. will treat all data in its object as volatile. This does NOT
  52. help "volatile-correctness"; just like with "const-correctness", 
  53. you have to program carefully to attain it. Even worse, the volatile
  54. member functions will be less efficient because of this
  55. characteristic, a drawback which does not arise in const-correct
  56. class design.
  57.  
  58. So; what do you think? Would it appeal to you that you could make
  59. an object safe for thread sharing by declaring it volatile? Or
  60. is this a useless concept?
  61.  
  62.                         David Byrden
  63.  
  64.  
  65.            || My opinions ARE those of my employer. ||
  66.  
  67.  
  68.  
  69.